Archive Magazine CD 1995/Archive Magazine CD 1995.iso/text/hints/volume_07/issue_02

Text File | 1995-02-16 | 13.1 KB | 246 lines

Hints and Tips
7.2
•    ArcDFS under RISC OS 3 − It has been reported on numerous occasions
that ArcDFS doesn’t work under RISC OS 3 − not true! (Or at least only
partly.) If a disc reports a failure, change the disc TITLE (using
appropriate option) to “”, i.e. an empty string, and hey presto!!
7.2
Why is that necessary? I have not yet had a chance to bury myself in the
code to find out, I’m afraid.
7.2
Note: The only other option that doesn’t work is Free, but personally I
don’t think that’s much of a problem. Format and Verify both work OK.
7.2
P.S. Make sure the Step timings are set to those values given in the
original documentation, as they are reset when upgrading to RISC OS 3.
R. George, Cambridge.
7.2
•    Grey Scales − I frequently use Draw to produce diagrams for inclusion
in text produced using Impression, or for independent printing. The
drawing package which comes with RISC OS 3 generally satisfies my needs.
7.2
One facility which I often need is a grey scale which will produce
distinct shades on my LaserDirect printer, with the minimum of
‘graininess’. Ignore the adverts which proclaim 256 Grey Shades! If you
need a ‘seamless’ transition from black to white, this is fine, but if
you want to print blocks of greys which all look different, you will be
lucky to manage 16 shades.
7.2
The simplest approach to this problem is to try using the colours on the
palette. It can be helpful to have the features of your diagram
highlighted in blue, red, green, etc on the screen, but how will they
appear printed in black-and-white? If you use the default palette (which
I do not!) the 16 colours come out in various shades of grey, as shown
below. The squares are labelled with the appropriate colour numbers, and
arranged from white to black. These squares appear on my Impression
screen, of course, in glorious technicolour.
7.2
I cannot be sure how this will turn out if Paul prints it in Archive,
but on my printer there are only seven, perhaps just eight,
distinguishable shades. They are all fairly grain-free, printed at
600×600 dpi, so a suitable selection can be used. If you want them to
appear on the screen as shades of grey, use ‘colours’
0  ◰2  1  2  3  4  5(?)  7. If you prefer them displayed in colour, use
the series 0  ◰2  9  ◰4  ◰5  ◰0  5(?)  11  7.
7.2
I have continued this investigation to attempt to find the best possible
grey scale using colours not necessarily on the palette. I have
restricted my investigation to grey ‘colours’, i.e. those using the
same, or similar, intensities of red, green and blue. That is enough to
be going on with!
7.2
!Draw allows you to select each of the three components on a scale
0−255. The !Palette utility only allows 16 intensity levels for each
component (producing the 4096 standard colours), so I have started with
this restriction. Representing the 16 degrees of intensity by the hex-
digits 0−F, and allowing a difference of only one between the three
components, I have devised the 16-grey-shades scale shown below.
7.2
How these colours appear on your screen depends on what palette you are
using. In front of me now, I can see shades of buff/brown, because I
have modified the standard, rather harsh, palette. You could try setting
up a palette using these as colours 0−15. The result on the screen is
pretty horrible! The result in print, however, is quite good, although
the lighter shades are a bit grainy.
7.2
Using the Fill Colour facility of Draw gives us greater flexibility,
because we can select from 0−255 for each primary colour. To keep things
fairly simple, I have tried only ‘pure grey’ shades, in which the
intensities of red­green­blue are always the same. This gives 256 shades
to try.
7.2
Using this technique, LaserDirect clearly does not print 256 shades.
Groups of four consecutive shades always appear identical, so our
selection comes down to 64 shades. I printed blocks of these shades,
each identified by the intensity number used for each of the three
components, 0 = black ... 255 = white. The shades which show the least
grain are, for some reason, those numbered 243  235  227  219  etc, i.e.
those whose codes are 8k+3.
7.2
There are 32 such shades, but adjacent ones are very similar in print,
often apparently identical. In an attempt to create a usable scale, I
have selected ten of these codes (235 219 203 187 171 155 139 123 99 and
67) plus 0 (black) and 255 (white). These are the shades which I will
try for my next few Draw diagrams. Even these shades show little
difference between adjacent pairs, and it is desirable to use alternate
ones only, if possible.
7.2
Colin Singleton, Sheffield.
7.2
•    Hard disc usage − How much space do my hard disc files occupy? The
answer depends on how I try to measure them! My investigations resulted
in the recovery of 5.6Mb (13%) from an unexpected source which I don’t
think has been mentioned previously in Archive.
7.2
We all know that the disc usage figures given by *Free and *Count are
different. *Count returns the total number of data bytes in the files,
in my case 22.3Mb. *Free returns the total number of bytes used (or
reserved) on the disc, in my case 42.8Mb. These are different for at
least two reasons.
7.2
Firstly, disc space is allocated to files in units which vary from drive
to drive. In the case of the Acorn SCSI on my A540, this unit is 1Kb.
Hence, on average, 512 bytes is wasted at the end of each file − this is
included in the bytes used returned by *Free, but not by *Count. For the
5,134 files on my drive, this totals 2.5Mb.
7.2
Secondly, some space is reserved for each Directory Header. The Index
occupies 2Kb, irrespective of the drive and filing system which, for my
1204 directories, amounts to 2.4Mb, increasing *Count to 24.7Mb.
However, SCSIFS reserves a larger allocation per directory, as noted by
several Archive readers, including Steve Drain (Archive 5.12). On the
A540, each directory is allocated 15Kb, of which only 2Kb is occupied by
the Index. Some of the rest may, if I am lucky, be occupied by small
files subsequently created within the directory. If I am unlucky, I lose
13Kb per directory. For my 1204 directories, this could amount to
15.3Mb.
7.2
Adding this 15.3Mb to the 2.5Mb noted above, gives a maximum wastage of
17.8Mb. The actual discrepancy, however, was 42.8 − 24.7 = 18.1Mb, so
there must have been something I hadn’t discovered. In order to
investigate, I considered my disc directories in three groups, as
identified in the table overleaf.
7.2

7.2
The largest is headed by a directory called Documents. This contains all
my Impression documents, plus a large number of drawfiles and several
hundred old First Word Plus text files retained for reference. When I
discovered the 13Kb per directory wastage, I realised that Impression,
which normally uses three directories per document, was wasting a great
deal of space.
7.2
I tackled this problem some time ago, by saving most of my Impression
documents as Text only. This Impression feature in fact stores the
Styles with the text, but does not store graphics or frame data. If I
drag one of the resulting text files onto the Impression icon on the
iconbar, this displays the text in its original fonts, sizes, etc. If,
instead, I drag the text of a letter into the document which contains a
‘blank’ letterhead, the letter is restored exactly as it was originally
created − provided it contained no graphics and no frames other than
those defined in the letterhead document.
7.2
I was thus able to store most of my Impression documents as Text only,
and recover several megabytes, without losing anything. This was done
some months ago, before the exercise I am describing here. At that time,
I also compressed all these ‘document’ files, using Compression and they
are now read and written using Cfs. Some of the other directories on my
disc are also held in compressed form and are identified below as Other
Cfs. The rest (mainly fonts and software) are not compressed and are
identified as Non-Cfs.
7.2
The table shows the *Count for each group of files and the *Count
obtained via Cfs, which shows what the count would have been if the
files had not been compressed. For interest, I have also shown the sizes
of the backups for each category. These were obtained using by !Backup,
into a temporary directory on the same disc and noting the *Counts of
the backup data directories created (excluding the recovery software
stored with the backup data). !Backup uses !Spark compression which, we
can see from the figures, has some effect on the Non-Cfs files. For the
others, however, no further compression is possible and the backup
actually uses more space than the live files, owing to the directory
structures and other parameters stored by !Backup.
7.2
In order to assess the Actual Mb used for each group, I copied (by
dragging) each in turn into a temporary directory on the same disc and
noted the decrease in *Free bytes. Then I discovered that the three
figures obtained did not total the Used bytes given by *Free for the
whole disc − the discrepancy being over 5Mb. After some experimentation,
I concluded that the copying process did not produce a precise ‘clone’
occupying the same space as the original. The only way to discover the
space occupied by a group of directories is to delete it and note the
increase in *Free bytes.
7.2
Hence I copied each group in turn, then deleted the original, rather
than the copy, and noted the change in total usage arising from the
deletion rather than the copying. The copies were then retained in place
of the originals. This process not only revealed the true original
sizes, but also gained 5.6Mb free space, because the copies occupied
less space than the originals!
7.2
Where did this windfall come from? The first point to note is that it
was all gained in the Documents directories. These have been very active
in the past. Apart from the usual process of addition and amendment of
documents, the filing system has also had to endure the process of
replacing most of the Impression documents with text files, the
compression of all the files and, recently, a major exercise of
restructuring the directories and renaming most of the files. Many of
the recent changes were made by copying files, then deleting the
originals, rather than by renaming. All this activity must have produced
considerable small-scale fragmentation of the free space, which is
perhaps not mapped and included in the *Free bytes. *Compact (which
should not be needed with this filing system) did produce a
simplification of the free space *Map, but did not change the number of
*Free bytes. Copying the files in sequence, however, produces a new
directory with no fragmented waste.
7.2
As a result of all this, I can now calculate the wasted space as 8.5Kb
per directory, instead of an apparently impossible 13.3Kb. If I could
recover all of this, I would save another 10Mb in total, but that seems
to be impossible. I could recover perhaps three quarters of it by re-
formatting the disc using a smaller File Allocation, except that I don’t
want to do that unless it is really necessary, and in any case, I don’t
appear to have the right Format program ...!  Colin Singleton,
Sheffield.
7.2
•    Image enhancement − I think I can offer a solution to Cain Hunt’s
request for a cheap image enhancer (7.1 p26). With hindsight, I might
have included the information in the notes on colour printing (7.1 p35).
Version 0.90 of Acorn’s !ChangeFSI application comes ‘free’ on the RISC
OS 3.1 Support Disc and its many facilities include most of the sprite
processing options I suggested; brightening and gamma correction for
example. It also accepts some foreign formats (e.g. TIFF), converting
them to sprites.
7.2
The documentation is not so hot. There seems to be nothing between the
rather sketchy notes starting on page 207 of the RISC OS 3 Applications
Guide and the detailed but very complex FSIinfo file in the !ChangeFSI
directory. However, this desktop application is intuitive to use, and
trial and error will often produce the desired result. Although it is
possible to apply two or more processing functions in parallel, I do
support the notes’ recommendation to operate on an unmodified file and
try changing only one parameter at a time.
7.2
The only process I would like to see added to !ChangeFSI is Chameleon’s
‘Weaken’ function which, for me, seems to give more effective control of
colour sprites than Brighten.
7.2
I spotted a documented facility in !ChangeFSI which allows very large
output files to be built in ‘strips’ using the parameter ChangeFSI
<source address><destination address>28-max<n> where n is the desired
size of the strip, e.g. 512Kb. I wonder if some very clever person might
be able to use this as a basis for a utility to transfer large
TIFF files between Archimedes/PCs/Macs, split between two or more MS-DOS
floppy discs?
7.2
As a further postscript to the colour printing notes, a reader has
recommended Hewlett Packard HP 92296U transparencies for my Canon LBP-4;
about 32p each. I’ve since tried them and the results, especially on 600
dpi graphics, are excellent.  Jim Nottingham, York.
7.2
•    Indelible ink − At long last, there is an indelible ink refill
available for HP Deskjet cartridges. They are available from Misco
Computer Supplies, Faraday Close, Park Farm Industrial Estate,
Wellingborough, NN8 6XH. A two-refill kits costs £13 plus postage.  Mike
King, Guernsey.  A